Before an application program can first be used, it must typically be installed onto a computer system. The installation procedure generally involves copying executable and data files (the "program files") relating to the application program from a source location to an installed location on the computer. Typically, the source location is an installation disk or location on a network server accessible by the computer system. Often the program files are stored in a compressed format to conserve storage space.
Before proceeding further, a brief discussion of terminology is needed. The installer application described herein recognizes three principal elements: products, features and components. A "product" represents a single, entire application program, such as the Microsoft Office application program marketed by Microsoft Corporation of Redmond, Wash. Each product has a globally unique identifier known as a Product Code, which allows products to be distinguished. Each product is made up of one or more features. A "feature" is a module that a user may choose to install or execute. Features typically correspond roughly to the functional features of the product itself, such as a "Proofing Tools" feature or a "Word" feature. Each feature is essentially a grouping of components and may also include other features. For example, the "Word" feature may include the "Proofing Tools" feature, and the "Proofing Tools" feature may include a "Spell Check" feature. So a feature, which is a module of a product, can also have its own features. Features need not be globally unique and therefore may be identified by any appropriate means, such as with a textual feature identifier.
A "component" is a collection of files, registry keys, and other resources that are all installed or uninstalled as a unit. Components are the building blocks of the product that are not exposed to the user. A resource, such as a file or a registry key, may be part of only one component. Two components may not share the same resource, whether they are part of the same product or parts of different products. Each component has a globally unique identifier known as a Component Code. One resource within the component is designated as a "key file." The existence of the key file is used by an installer as an expedient means of checking whether a component is correctly installed or not. The installer only verifies the existence of the key file, unless a problem arises. If a problem arises, then the installer will perform a more extensive check of the files. The key file may be any resource, such as a file or registry key, within the component. A list of sources for installing a desired component is stored in a source list key.
Application programs use a variety of installation technologies to copy the program files from the source location to the computer system. InstallShield, Seagates' WinInstall or Great Lakes Software's Wise Installation System are tools commonly used for generating application installation packages for Microsoft Corporation's Windows platforms. Web-based components such as ActiveX controls may use IExpress packages, which are selfextracting executables with a simple file copy and registry capability.
An application program will often include a special application program (the "set-up program") for administering and performing the installation procedure. Generally, the set-up program is unique to the application program and is customized to install the program files from a predetermined source location to pre-configured locations on the computer system. Often the user is provided the option of redirecting the installation of the program files to other locations on the computer system.
The typical set-up program, such as the one currently provided by Microsoft Windows, not only installs the program files to the computer system but also creates entries in a central registration database, such as a system registration database (the "system registry"), which identify the locations of the program files on the computer system. The location may be identified by a "path" to a particular directory or folder of the computer system in which the program files reside. The system registry is typically maintained by the computer system's operating system. While executing, the application program generally queries the operating system for the path to an installed program file, the operating system looks up the path in the system registry, and the operating system returns the path to the executing application program.
This set-up program provides only a very rudimentary way for system administrators and users to know which applications they have installed on their machines and to manage these installed applications. The operating system for Microsoft Windows contains an "Add/Remove Programs" control panel, and this control panel is driven by a standard set of registry entries. Windows 95, Windows 98 and Windows NT 4.0 can uninstall a product by invoking a command line provided by this registration information. Products such as Microsoft Systems Management Server can help manage installed applications in a centrally-managed environment. However, these products are limited by the information and control that individual application setup scripts choose to provide, and they do not facilitate source management for users who are in effect their own system administrators.
A limitation of current installation technologies is that they look for the program files at a predetermined location. Current installation technologies will not perform satisfactorily if that location is not available. For example, users frequently install software over a network. The installer software will look for the needed program files at a predetermined location, usually a server. If the server goes down while a user is installing these program files from the network, the user is unable to install the desired program files and is without recourse. Similarly, if the installer software expects to find the needed program files on removable media, and the removable media is not mounted when the software installer needs these program files, the installation will fail. Even something as simple as the expected program file having been inadvertently erased from the expected location will bring the software installation process to a halt.
Typically, the Add/Remove Program control panel is used to invoke "maintenance mode" setup for a product. For example, if the user decides that he now wants to install the Spell Check feature though he chose not to do so during the original install, the user goes to the Add/Remove control panel and re-runs the setup procedure to install the Spell Check feature. Depending on the user interface of the particular program, if the original installation source is no longer available, the application will either fail or will interrupt the installation process to prompt the user to locate a valid source manually. The user would either have to find a new source, or the install would fail.
When a user installs a product, he may select all of the product's features to run from the network. If the network goes down, the user is unable to use the product's features because the "run-from-source" features could run only from the network source. Users and administrators want a system by which the installer will go to a back-up location to get the needed modules if the network server goes down. This can be done via a distributed file system (DFS). A DFS keeps track of files stored across multiple networks. It converts file names into physical locations. However, everyone does not have access to a DFS, and even where a DFS is available, the administrator must manually re-map the file system before the software installer will look in an alternate location.
The problem of finding a valid source location for a computer program file can arise in a number of different situations: when the product is first installed, when an installed product is reconfigured, or when a product is configured to "run-from source". Each of these situations will now be briefly described.
With the typical initial installation procedure the user will mount a CD or access a network share and click on the "install" executable. Finding a valid installation source is typically not much of an issue in this situation, since the user would not have been able to invoke the "install" executable if the installation source were not available. However, under certain circumstances it is possible to initiate an original install other than from an install executable at the source location, for example, from the Add/Remove control panel of Microsoft Windows. The installation software will look to a predetermined source location for the needed software code, and if the source location is not available, the installation will fail.
Subsequent to the original installation of the product, occasions may arise when the user needs to perform additional installations. For example if the user originally did not install the spelling checker but subsequently decided this feature was needed, the user would need to install this feature. In the case of Microsoft Windows software the user can access the Add/Remove control panel to invoke "maintenance mode" setup for a product. The Add/Remove control panel looks to the source from which the original installation was performed. If the source from which the program was originally installed is unavailable, then the user either has to find a new source manually or the install will simply fail.
As an alternative to the Add/Remove control panel, certain applications may install software "on demand." "On demand" installation is really just an automated form of "maintenance mode" installation. When the user selects the spelling checker from, for example, the word processing application, and the selected feature had not previously been installed, the application can automatically install the requested feature. If the original installation source was not available at the time the "on demand" installation is attempted, an alternate source must be located or the installation will fail.
The need to find a valid source location can also arise in circumstances unrelated to installation. For example it is possible for a user to install a product from a network location and configure all of the features to run from the network, rather than having the features installed on the user's local hard drive. When the features are configured to "run from source" and the network then goes down, the features cannot run.
In all of these instances there is a need for a method and software product which will look for alternate source locations in the event that a primary source location is unavailable.